Every issue now carries three additive identity fields:

- Owner: the topmost stable controller of a Pod problem (Pod→Deployment,
  not the intermediate ReplicaSet), resolved at detection time via the
  existing topOwnerForPod and carried on k8s.Problem alongside the
  RestartCount/LastTerminatedReason crash context.
- GroupingScope: workload|service|pvc|ingress|node|unknown — the subject's
  coarse bucket (drives the future UI section, part of the ID).
- ID: deterministic cluster-local hash(scope, subject key, category),
  identical for every member row that rolls up to the same subject+category.
  The hub namespaces it by cluster_id for global uniqueness.

Subject = the topmost owner when one was resolved (member pods key on their
workload), else the resource itself. resourceKey reuses
pkg/audit.ResourceKey so issue grouping and audit deep-links share one key
format rather than drifting.

Purely additive — rows are not yet collapsed; the shared ID is the handle
the collapse fold keys on (next slice). No consumer contract changes.

GroupIssues collapses the flat evidence rows into the public operational
model — one row per shared id (subject+category). A Deployment whose 3 pods
all ImagePullBackOff is one issue with affected:{pods:3} + bounded member
refs, not three rows.

- /api/issues + MCP issues return grouped rows by default; the cap now
  counts issue groups, not replica fan-out.
- /api/issues?view=flat returns the raw pre-fold evidence rows for
  debugging ("what folded into this group?"). MCP stays grouped-only —
  agents use get_resource/get_events for raw state.
- Compose() stays flat internally, so summarycontext's per-resource index
  is unchanged; Filters.Grouped gates the fold.
- Representative rules (deterministic): severity = max member, category =
  shared, subject = topmost owner, reason/message/crash-context from the
  worst member, age = oldest onset, last_seen = newest, members sorted +
  capped at 10 with members_truncated past that.

Table-tested — grouping bugs are trust bugs; every consumer inherits them.

The presentation sibling to the Checks queue (ChecksView): one row per
grouped issue (subject + category), severity rail + pill, single-open
accordion expanding to the diagnosis (reason/message + pod crash context)
plus the subject and affected-member deep-links. Consumed by BOTH OSS
single-cluster and the hub fleet view (the host wires resourceHref /
onResourceClick / clusterLabel) so the two surfaces can't diverge.

Reuses the established shared atoms (ClusterName, EmptyState) and the EXACT
Checks severity hues (critical=red, warning=amber = Checks medium) so the
two queues read as one product. Identity (IssueResourceRef + resourceKey)
matches the Checks contract + audit.ResourceKey; named IssueResourceRef to
avoid colliding with the core single-cluster ResourceRef (same reason
Checks uses CheckResourceRef). Faceting stays the host page's job
(FleetPageShell), so there are no in-component filter chips.

Types mirror radar's grouped Issue (internal/issues.GroupIssues).

…es identity

New pkg/subject is the one resolver the platform plan calls the #1 prerequisite:
- Tier-1 Subject = owner-collapsed root controller (Pod->RS->Deployment,
  Pod->Job->CronJob), with explicit bare/Node/operator-CR anchors. Deterministic,
  label-free. Walks via injected OwnerResolver/OperatorRootHook so the package
  imports neither internal/* nor pkg/topology.
- Tier-2 AppOverlay = 8-tier declared-key precedence (Flux/Argo/Helm tiers 1-5
  consolidated from managedby.go in its native order argo-instance<Helm; labels
  6-8 net-new) with provenance + confidence + retained conflicts[]; nil when raw
  wins (bare-app opt-in).
- IssueID/CheckID + ScopeForKind move here. IssueID is byte-identical -> no re-key.
- internal/issues/identity.go:enrichIdentity migrated to consume it (Scope aliased).

Topology determineGroupKey migration (consume Subject for identity + AppOverlay
for grouping) is the next step. Verified: go build/vet/test green for pkg/subject
+ internal/issues.

…aps, CRD noise

#1 detector monotonicity (internal/k8s/health.go): classify crashloop from
   RestartCount + LastTerminationState, stable across Waiting->Running->Waiting
   so the category-hashed issue_id stops churning.
#2 suppress parent workload_degraded/rollout_stalled when an equal-or-worse child
   symptom exists on the same subject — severity-gated so a critical rollup is
   never downgraded to a warning child.
#3 PVC Lost + Job/CronJob failures classified (were discarded to unknown).
#5 CRD-condition noise floor: transient-aware via shared
   packages.IsTransientConditionReason (one source of truth with the GitOps path).
+ table tests. Verified: go build/vet/test green (internal/issues, internal/k8s, pkg/packages).

…umented

Round 2 of the canonical-primitive review — close the paths back to
'management edge as identity':

- HeuristicPodOwnerResolver no longer falls back to refs[0] when there's no
  controller ownerRef. The contract says controller-only; the fallback
  collapsed a pod under an arbitrary NON-controller owner. Now a pod with only
  non-controller refs resolves to itself (bare). New test pins both arms.
- Resolve doc corrected: obj feeds ONLY the Tier-2 overlay; ownership ALWAYS
  comes from the injected resolver. Resolve(ref, obj, nil, …) yields a bare
  Subject even if obj has ownerRefs — the previous 'obj supplies BOTH' framing
  was misleading. Spelled out that a pod owner-walk needs an injected resolver.
- Scrubbed EdgeManages / walkTopmostOwner from Tier-1 language in the Subject
  doc and OwnerLookup (operatorroots.go) — those comments are the #823
  integration guide, and 'derivable from the EdgeManages chain' reintroduced
  the exact ambiguity the contract fix removes. Now: controller ownerReferences
  / controllerRef-derived edges only.

Cross-cluster audit (gke-management) surfaced a false-positive class: PVCs bound
to a WaitForFirstConsumer StorageClass sit in Pending BY DESIGN until a consuming
pod is scheduled — dormant/scaled-to-zero/orphaned volumes stay there forever and
aren't a fault. The detector flagged every Pending PVC >5min regardless of
binding mode, lighting up benign awaiting-consumer volumes.

pvcAwaitsFirstConsumer resolves the PVC's StorageClass (explicit or cluster
default) and suppresses the row when binding mode is WaitForFirstConsumer — a
genuinely-stuck consumer still surfaces as an unschedulable pod via the
scheduling source. Immediate-binding Pending (real provisioning failure) and
missing-StorageClass (separate detector, critical) are unaffected; verified the
kind-bench missing-SC PVC still flags. Also added a message on the remaining
Pending rows (was bare 'Pending').

…tectors, chronic onset, total rep order

Review round on the identity/grouping spine:

- ID discriminator gains a stable cause Fingerprint so distinct causes on one
  subject+category no longer collapse into a single row (a workload missing both
  a ConfigMap AND a Secret was one missing_config_ref showing only one target).
  The missing-ref detector sets it from the target-bearing message (stable,
  deterministic — NOT the flapping reason, which would re-key on refresh);
  unknown keys on source+reason; every single-cause category stays category-only
  and byte-identical (no re-key). Test pins split + fold + no-re-key.
- Curated CAPI/GitOps detectors route the all-scope path through ListWatched
  instead of List(gvr,"") — the latter is cluster-wide-only and silently drops
  namespace-scoped contents in namespace-restricted installs (the generic
  fallback already did this). Verified no regression on a cluster-wide install.
- FirstSeen no longer resets to now for detectors without a duration: HPA/CronJob
  now stamp AgeSeconds (resource age), and fromProblem falls back to AgeSeconds
  when DurationSeconds is 0 — chronic issues stop sorting as fresh.
- betterRepresentative is now a true total comparator (group/kind/ns/name/source/
  reason/message), so the donated representative is deterministic regardless of
  input order.

(The 5th finding — HeuristicPodOwnerResolver refs[0] fallback — was already fixed
in 2b16a5e.)

…inks

- Extract issues.ListResponse + NewListResponse; /api/issues (HTTP) and the MCP
  issues tool both build from it instead of hand-rolling identical maps, so the
  contract can't drift (and the hub mirrors one shape). MCP keeps its narrowHint;
  both keep visibility. Wire output unchanged.
- Local Issues view surfaces truncation: useIssues now carries total/
  total_matched, and IssuesPane shows 'Showing N of M (capped)' when the queue
  was windowed — local Radar no longer presents a capped list as complete.
- Issue/Audit resource clicks encode the opened resource in the URL
  (?resource=ns/name, the resources view's own deep-link shape) so refresh/share
  keeps the drawer open instead of dropping it.

…nt contract

The issues tool exposes grouped logical subjects, but the agent's follow-up
(get_resource/list_resources/search/diagnose) contradicted it. Three fixes so
an AI SRE agent gets the same picture on drill-down:

- BuildIssueIndex now composes GROUPED issues and counts each against its
  subject AND every affected member, so get_resource Deployment surfaces the
  Deployment-grouped crashloop (was issueCount=0 — keyed only by the evidence
  Pod). issueCount is now consistent with the issues tool.
- diagnose returns relatedIssues — the grouped issues whose subject or member
  is the diagnosed object — so the agent sees 'crashloop + missing ConfigMap +
  HPA can't-scale' up front instead of re-deriving from raw logs. (No issue-id
  input, per scope.)
- The issues CEL filter schema now documents all runtime bindings (category,
  category_group, grouping_scope, restart_count, last_terminated_reason,
  first_seen) and leads with first_seen — agents were missing strong filters
  like category_group=='startup' or restart_count>10.

…#1 + #13)

Conceded from review: get_resource/diagnose built issueSummary via a SEPARATE
flat-by-exact-resource path (computeMCPIssueSummary / computeIssueSummaryForResource)
that BuildIssueIndex never touched — so get_resource Deployment/web returned an
empty summary while the issues tool showed it broken. And both BuildIssueIndex
and RelatedIssues iterated the grouped issue's inline Members (capped at
maxInlineMembers=10), dropping pods #11+ of a large fan-out.

Both now resolve a resource's grouped issues from FLAT evidence (uncapped) +
the resolved owner, keyed/deduped per grouped-issue ID:
- RelatedIssues matches grouped subjects AND every flat evidence row.
- BuildIssueIndex counts distinct grouped issues per resource (each evidence
  resource + its owner).
- computeMCPIssueSummary + computeIssueSummaryForResource route through
  RelatedIssues, so get_resource on a workload (or any affected pod, capped or
  not) surfaces the same grouped issues the issues tool shows.

Tests pin owner-rollup AND the uncapped (>10 members) case.

- #2 (Service): a Service that is BOTH no-ready-endpoints AND has an unresolved
  named targetPort now stays two issues (distinct fixes — the workload vs the
  Service port spec) via stable fingerprints, instead of collapsing under one
  service_no_endpoints row.
- #5 (cluster): removed the 'cluster' CEL binding + the always-empty Issue.Cluster
  field + its activation projection. A single Radar is one cluster, so
  Issue.Cluster was always empty and a forwarded 'cluster == x' matched nothing —
  the advertised filter returned the wrong answer. Cross-cluster scoping is the
  hub's clusters=/target mechanism (applied at fan-out), not a per-issue
  predicate. MCP/filter docs updated to say so.

…ollout deadlocks

- New pdb_blocks_evictions detector: a PodDisruptionBudget that allows 0
  voluntary disruptions while all selected pods are healthy (maxUnavailable=0
  or minAvailable>=replicas) silently blocks node drains and cluster upgrades.
  Keyed on status.DisruptionsAllowed==0 with structural guards (observed
  generation current, healthy>=desired) so transient zero-budget during a
  real outage isn't flagged.
- Enrich the existing 'Rollout stuck' row: when a stuck Deployment mounts a
  ReadWriteOnce PVC and isn't strategy: Recreate, append the root cause + fix.
  The surge pod can't attach the volume the old pod holds — the classic
  rollout deadlock, named on the row that's already firing (no new noise).

…s, fix merged doc, complete category labels

- normalizeImagePullMessage: drop the redundant 'lookup .* no such' branch
  (already covered by 'no such host') — removes the unbounded .* CodeQL flagged.
- Remove unused resourceKey/resourceRefKey from the issues module (Checks owns
  its own copy; no issues consumer).
- Restore pvcAwaitsFirstConsumer's doc comment (had merged into resourceAge's).
- Add curated labels for pod_security_violation, control_plane_not_ready,
  machine_not_ready.

…a goal, Flux match precision, Argo reason format; CAPI/namespace CRD fallback

Detector:
- Deployment desired count uses schedDesiredReplicas (spec is the goal; nil→1;
  a scale-down's terminating pods no longer inflate the denominator).
- A ProgressDeadlineExceeded rollout supersedes the workload_degraded row for
  the same Deployment — one incident, not two redundant rows.

Classification:
- Flux group match tightened 'fluxcd' → 'fluxcd.io', consistent with the
  sibling argoproj.io / cert-manager.io matches and collision-safe.
- Argo Rollout Reason formatted via condTypeReason ('Progressing:
  ProgressDeadlineExceeded') to match every other condition row; InvalidSpec
  guarded against doubling when reason restates the type.

Generic CRD fallback:
- isCuratedCRDKind is kind-specific for CAPI (core Cluster/Machine/KCP/MHC),
  so provider CRDs (AWSMachine, bootstrap configs) still get the generic
  condition fallback instead of being silently skipped.
- Skip cluster-scoped CRDs when an explicit namespace filter is set.

Tests cover CAPI provider-CRD fallback and namespace-scoped skip.